In prior art devices that implement command and data reordering, commands and data are typically received in one or more queues referred to as "command queues". Eventually, the commands and data are dequeued from the command queues into a reordering domain where arbitration logic reorders the commands and data for execution or processing according to certain optimization policies.
Occasionally it is necessary to prevent commands and data from being reordered ahead of a previously received command or data value. This is accomplished according to one prior-art technique by using a special command called a "fence" command. In essence, data and commands received after a fence command are prevented from being reordered for execution or processing ahead of data and commands received before the fence command.
In prior-art devices that support the use of fence commands to control command and data reordering, fence commands are typically enqueued in the command queue like other commands and therefore consume storage space in the command queue. One disadvantage of this prior-art technique allocating queue storage to fence commands is that a command queue designed to hold a specified number of executable (i.e., non-fence) commands must be enlarged to hold a potentially unlimited number of fence commands. This consumes device resources and results in increased cost. This particularly true in the context of an integrated circuit, where enlarging the command queue results in increased gate count and potentially increased die size.